Universal gateway devices, systems and methods for integrating disparate protocols

ABSTRACT

A universal gateway device includes a first network interface circuit and a second network interface circuit. The first network interface circuit is utilized to communicate over a first network associated with an Internet of Things (IoT) management system utilizing a first communications protocol. The second network interface circuit is utilized to communicate over a second network associated with an IoT device utilizing a second communications protocol that is different from the first communications protocol. The first network interface circuit generates a virtual device representation of the IoT device on the first network. The virtual device representation is utilized to communicate data from the IoT device over the first network utilizing the first communications protocol.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/678,468 filed Nov. 8, 2019, now U.S. Pat. No. 11,503,121, the entiredisclosure of which is incorporated by reference herein.

BACKGROUND

The present disclosure relates generally to IoT management platforms andsystems. The present disclosure relates more particularly to universalgateway devices, systems, and methods for integrating disparateprotocols.

The Internet of Things (IoT) is a network of interconnected objects (orThings), hereinafter referred to as IoT devices, that produce datathrough interaction with the environment and/or are controlled over anetwork. An IoT management platform is used by application developers toproduce IoT applications for the IoT devices. Generally, IoT managementplatforms or systems are utilized to register and manage the IoTdevices, gather and analyze data produced by the IoT devices, andprovide recommendations or results based on the collected data. However,in many cases, IoT devices or subsystems may not easily interface withthe IoT management platform or system. For example, where some of theIoT devices or subsystems are provided by third-parties, the third partyIoT devices or subsystems may communicate via disparate or proprietarycommunication protocols, which may be incompatible with the IoTmanagement platform or system. This inability to communicate with theIoT management platform or system using a communication protocol used orotherwise recognized by the IoT management platform or system canincrease time to setup, commission, maintain, and/or monitor the thirdparty IoT devices or subsystems. Further, these disparate or proprietaryprotocols are generally not published or disclosed by the third parties,which can limit the supply of control solutions to only those offered bythe third parties. In this case, others are prevented from competing inthis space to offer solutions with better design, functionality, andpricing.

As the number of IoT devices used in various sectors increases, thenumber of disparate or proprietary protocols used by the IoT deviceshave been increasing. Accordingly, devices, systems, and methods forintegrating disparate or proprietary protocols may be desired.

SUMMARY

One implementation of the present disclosure is a universal gatewaydevice including: a first network interface circuit configured tocommunicate over a first network associated with an Internet of Things(IoT) management system utilizing a first communications protocol; and asecond network interface circuit configured to communicate over a secondnetwork associated with an IoT device utilizing a second communicationsprotocol that is different from the first communications protocol,wherein the first network interface circuit is configured to generate avirtual device representation of the IoT device on the first network,the virtual device representation configured to communicate data fromthe IoT device over the first network utilizing the first communicationsprotocol.

In some embodiments, the first network interface circuit may include avirtual network simulation module configured to communicate with thesecond network interface circuit to generate the virtual devicerepresentation of the IoT device.

In some embodiments, the second network interface circuit may beconfigured to: receive a data packet associated with the IoT device overthe second communications protocol; store the data packet according to adata structure associated with the second communications protocol; andtransmit the data packet to the virtual network simulation module.

In some embodiments, the virtual network simulation module may include avirtual network manager, and the virtual network manager may beconfigured to generate the virtual device representation based on thedata packet received from the second network interface circuit.

In some embodiments, the virtual network manager may be configured to:generate a virtual device corresponding to the IoT device in a virtualdevice table based on the data packet, the virtual device having dataobjects corresponding to data points of the IoT device; receive a datavalue change associated with the IoT device from the second networkinterface circuit; and update one or more of the data objects based onthe data value change.

In some embodiments, the virtual network manager may be configured toinitially generate the virtual device to have an offline status, and inresponse to receiving the data value change, the virtual network managermay be configured to update the virtual device to have an online status.

In some embodiments, the virtual network manager may be configured toidentify a device type or address from the data packet, and to generatethe virtual device based on the device type or address.

In some embodiments, the second network interface circuit may beconfigured to: poll the IoT device to request data values for one ormore of the data points of the IoT device; parse the data values toidentify the data value change; and transmit the data value change tothe virtual network manager.

In some embodiments, the first network interface circuit may include: agateway executable module configured to detect the generation of thevirtual device, and to expose the virtual device on the first network toappear as a field device on the first network, wherein the gatewayexecutable module comprises a network layer configured to read dataobjects of the virtual device corresponding to data points of the IoTdevice to detect when the data objects are updated and to provide theupdated data objects to the exposed virtual device on the first network.

In some embodiments, the second network may be associated with aplurality of IoT devices, and the first network interface circuit may beconfigured to generate the virtual device representation of the IoTdevice to include at least some data points from other devices of theplurality of IoT devices.

Another implementation of the present disclosure is an Internet ofThings (IoT) management system including: an IoT management platformconfigured to communicate over a first network utilizing a firstcommunications protocol, the first network comprising one or moredevices associated with the first network; a second network comprisingone or more IoT devices configured to communicate over the secondnetwork utilizing a second communications protocol that is differentfrom the first communications protocol; and a universal gateway deviceincluding: a first network interface circuit configured to communicateover the first network utilizing the first communications protocol; anda second network interface circuit configured to communicate over thesecond network utilizing the second communications, wherein the firstnetwork interface circuit is configured to generate a virtual devicerepresentation of an IoT device from among the one or more IoT deviceson the first network, the virtual device representation configured tocommunicate data from the IoT device over the first network utilizingthe first communications protocol.

In some embodiments, the first network interface circuit may include avirtual network simulation module configured to communicate with thesecond network interface circuit to generate the virtual devicerepresentation of the IoT device.

In some embodiments, the second network interface circuit may beconfigured to: receive a data packet associated with the IoT device overthe second communications protocol; store the data packet according to adata structure associated with the second communications protocol; andtransmit the data packet to the virtual network simulation module.

In some embodiments, the virtual network simulation module may include avirtual network manager, and the virtual network manager may beconfigured to generate the virtual device representation based on thedata packet received from the second network interface circuit.

In some embodiments, the virtual network manager may be configured to:generate a virtual device corresponding to the IoT device in a virtualdevice table based on the data packet, the virtual device having dataobjects corresponding to data points of the IoT device; receive a datavalue change associated with the IoT device from the second networkinterface circuit; and update one or more of the data objects based onthe data value change.

In some embodiments, the virtual network manager may be configured toinitially generate the virtual device to have an offline status, and inresponse to receiving the data value change, the virtual network manageris configured to update the virtual device to have an online status.

In some embodiments, the virtual network manager may be configured toidentify a device type or address from the data packet, and to generatethe virtual device based on the device type or address.

In some embodiments, the second network interface circuit may beconfigured to: poll the IoT device to request data values for one ormore of the data points of the IoT device; parse the data values toidentify the data value change; and transmit the data value change tothe virtual network manager.

In some embodiments, the first network interface circuit may include agateway executable module configured to detect the generation of thevirtual device, and to expose the virtual device on the first network toappear as a field device on the first network, wherein the gatewayexecutable module includes a network layer configured to read dataobjects of the virtual device corresponding to data points of the IoTdevice to detect when the data objects are updated and to provide theupdated data objects to the exposed virtual device on the first network.

In some embodiments, the second network may include a plurality of IoTdevices, and the first network interface circuit may be configured togenerate the virtual device representation of the IoT device to includeat least some data points from other devices of the plurality of IoTdevices.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system view illustrating an IoT environment including an IoTmanagement platform in communication with various IoT devices via auniversal gateway, according to some embodiments.

FIG. 2 is a schematic view illustrating an IoT management system in moredetail, according to some embodiments.

FIG. 3 is a schematic view illustrating a universal gateway device ofFIG. 2 , according to some embodiments.

FIG. 4 is an interface diagram illustrating the interaction between thegateway executable module and the virtual network simulation module ofFIG. 3 , according to some embodiments.

FIG. 5 is a detailed view of a virtual device, according to someembodiments.

FIG. 6 is a flow chart illustrating a process for interfacing with anon-local or foreign network using a universal gateway device, accordingto some embodiments.

FIG. 7 is a flow chart illustrating a process for generating one or morevirtual devices, according to some embodiments.

FIG. 8 is a flow chart illustrating an interface process between anexternal network interface circuit and a virtual network manager,according to some embodiments.

FIG. 9 is a flow chart illustrating a process for exposing virtualdevices to a local or internal network, according to some embodiments.

DETAILED DESCRIPTION

Hereinafter, example embodiments will be described in more detail withreference to the accompanying drawings.

FIG. 1 is a block diagram of an IoT environment 100 according to someembodiments. The environment 100 is, in general, a network of connecteddevices configured to control, monitor, and/or manage equipment,sensors, and other devices in the IoT environment 100. The environment100 may include, for example, a plurality of IoT devices 102 a-102 n, acloud IoT management platform 104, one or more local devices 106, one ormore connected services 108, a universal gateway 112, and any otherequipment, applications, and devices that are capable of managing and/orperforming various functions, or any combination thereof. Some examplesof an IoT environment may include smart homes, smart buildings, smartcities, smart cars, smart medical implants, smart wearables, and thelike.

The cloud IoT management platform 104 can be configured to collect datafrom a variety of different data sources. For example, the cloud IoTmanagement platform 104 can collect data from the IoT devices 102 a-102n, the local devices 106, the connected services 108, and/or othersuitable external or internal services and devices. For example, IoTdevices 102 a-102 n may include physical devices, sensors, actuators,electronics, vehicles, home appliances, wearables, smart speaker, mobilephones, mobile devices, medical devices and implants, and/or otherThings that have network connectivity to enable the IoT devices 102 tocommunicate with the cloud IoT management platform 104 and/or becontrolled over a network (e.g., a WAN, the Internet, a cellularnetwork, and/or the like) 110. Further, the cloud IoT managementplatform 104 can be configured to collect data from a variety ofexternal systems or services (e.g., 3rd party services). For example,some of the data collected from external systems or services may includeweather data from a weather service, news data from a news service,documents and other document-related data from a document service, media(e.g., video, images, audio, social media, etc.) from a media service,and/or the like. While the devices described herein are generallyreferred to as IoT devices, it should be understood that, in variousembodiments, the devices referenced in the present disclosure could beany type of devices capable of communicating data over an electronicnetwork.

In some embodiments, IoT devices 102 a-102 n include sensors or sensorsystems. For example, IoT devices 102 a-102 n may include acousticsensors, sound sensors, vibration sensors, automotive or transportationsensors, chemical sensors, electric current sensors, electric voltagesensors, magnetic sensors, radio sensors, environment sensors, weathersensors, moisture sensors, humidity sensors, flow sensors, fluidvelocity sensors, ionizing radiation sensors, subatomic particlesensors, navigation instruments, position sensors, angle sensors,displacement sensors, distance sensors, speed sensors, accelerationsensors, optical sensors, light sensors, imaging devices, photonsensors, pressure sensors, force sensors, density sensors, levelsensors, thermal sensors, heat sensors, temperature sensors, proximitysensors, presence sensors, and/or any other type of sensors or sensingsystems.

Examples of acoustic, sound, or vibration sensors include geophones,hydrophones, lace sensors, guitar pickups, microphones, andseismometers. Examples of automotive or transportation sensors includeair flow meters, air-fuel ratio meters, AFR sensors, blind spotmonitors, crankshaft position sensors, defect detectors, engine coolanttemperature sensors, Hall effect sensors, knock sensors, map sensors,mass flow sensors, oxygen sensors, parking sensors, radar guns,speedometers, speed sensors, throttle position sensors, tire-pressuremonitoring sensors, torque sensors, transmission fluid temperaturesensors, turbine speed sensors, variable reluctance sensors, vehiclespeed sensors, water sensors, and wheel speed sensors.

Examples of chemical sensors include breathalyzers, carbon dioxidesensors, carbon monoxide detectors, catalytic bead sensors, chemicalfield-effect transistors, chemiresistors, electrochemical gas sensors,electronic noses, electrolyte-insulator-semiconductor sensors,fluorescent chloride sensors, holographic sensors, hydrocarbon dew pointanalyzers, hydrogen sensors, hydrogen sulfide sensors, infrared pointsensors, ion-selective electrodes, nondispersive infrared sensors,microwave chemistry sensors, nitrogen oxide sensors, olfactometers,optodes, oxygen sensors, ozone monitors, pellistors, pH glasselectrodes, potentiometric sensors, redox electrodes, smoke detectors,and zinc oxide nanorod sensors.

Examples of electromagnetic sensors include current sensors, Dalydetectors, electroscopes, electron multipliers, Faraday cups,galvanometers, Hall effect sensors, Hall probes, magnetic anomalydetectors, magnetometers, magnetoresistances, mems magnetic fieldsensors, metal detectors, planar hall sensors, radio direction finders,and voltage detectors.

Examples of environmental sensors include actinometers, air pollutionsensors, bedwetting alarms, ceilometers, dew warnings, electrochemicalgas sensors, fish counters, frequency domain sensors, gas detectors,hook gauge evaporimeters, humistors, hygrometers, leaf sensors,lysimeters, pyranometers, pyrgeometers, psychrometers, rain gauges, rainsensors, seismometers, SNOTEL sensors, snow gauges, soil moisturesensors, stream gauges, and tide gauges. Examples of flow and fluidvelocity sensors include air flow meters, anemometers, flow sensors, gasmeter, mass flow sensors, and water meters.

Examples of radiation and particle sensors include cloud chambers,Geiger counters, Geiger-Muller tubes, ionisation chambers, neutrondetections, proportional counters, scintillation counters, semiconductordetectors, and thermoluminescent dosimeters. Examples of navigationinstruments include air speed indicators, altimeters, attitudeindicators, depth gauges, fluxgate compasses, gyroscopes, inertialnavigation systems, inertial reference nits, magnetic compasses, MEMsensors, ring laser gyroscopes, turn coordinators, tialinx sensors,variometers, vibrating structure gyroscopes, and yaw rate sensors.

Examples of position, angle, displacement, distance, speed, andacceleration sensors include auxanometers, capacitive displacementsensors, capacitive sensing devices, flex sensors, free fall sensors,gravimeters, gyroscopic sensors, impact sensors, inclinometers,integrated circuit piezoelectric sensors, laser rangefinders, lasersurface velocimeters, LIDAR sensors, linear encoders, linear variabledifferential transformers (LVDT), liquid capacitive inclinometersodometers, photoelectric sensors, piezoelectric accelerometers, positionsensors, position sensitive devices, angular rate sensors, rotaryencoders, rotary variable differential transformers, selsyns, shockdetectors, shock data loggers, tilt sensors, tachometers, ultrasonicthickness gauges, variable reluctance sensors, and velocity receivers.

Examples of optical, light, imaging, and photon sensors includecharge-coupled devices, CMOS sensors, colorimeters, contact imagesensors, electro-optical sensors, flame detectors, infra-red sensors,kinetic inductance detectors, led as light sensors, light-addressablepotentiometric sensors, Nichols radiometers, fiber optic sensors,optical position sensors, thermopile laser sensors, photodetectors,photodiodes, photomultiplier tubes, phototransistors, photoelectricsensors, photoionization detectors, photomultipliers, photoresistors,photoswitches, phototubes, scintillometers, Shack-Hartmann sensors,single-photon avalanche diodes, superconducting nanowire single-photondetectors, transition edge sensors, visible light photon counters, andwavefront sensors.

Examples of pressure sensors include barographs, barometers, boostgauges, bourdon gauges, hot filament ionization gauges, ionizationgauges, McLeod gauges, oscillating u-tubes, permanent downhole gauges,piezometers, pirani gauges, pressure sensors, pressure gauges, tactilesensors, and time pressure gauges. Examples of force, density, and levelsensors include bhangmeters, hydrometers, force gauge and force sensors,level sensors, load cells, magnetic level gauges, nuclear densitygauges, piezocapacitive pressure sensors, piezoelectric sensors, straingauges, torque sensors, and viscometers.

Examples of thermal, heat, and temperature sensors include bolometers,bimetallic strips, calorimeters, exhaust gas temperature gauges, flamedetections, Gardon gauges, Golay cells, heat flux sensors, infraredthermometers, microbolometers, microwave radiometers, net radiometers,quartz thermometers, resistance thermometers, silicon bandgaptemperature sensors, special sensor microwave/imagers, temperaturegauges, thermistors, thermocouples, thermometers, and pyrometers.Examples of proximity and presence sensors include alarm sensors,Doppler radars, motion detectors, occupancy sensors, proximity sensors,passive infrared sensors, reed switches, stud finders, triangulationsensors, touch switches, and wired gloves.

In some embodiments, different sensors send measurements or other datato cloud IoT management platform 104 using a variety of differentcommunications protocols or data formats. Cloud IoT management platform104 can be configured to ingest sensor data received in any protocol ordata format and translate the inbound sensor data into a common protocolor common data format. For example, in some embodiments, the cloud IoTmanagement platform 104 operates over a local (or internal) networkassociated with the cloud IoT management platform 104. In someinstances, the IoT devices 102 may operate over other networks (e.g.,network 110) that may operate using protocols that are not compatiblewith the local (or internal) network associated with the cloud IoTmanagement platform 104. Accordingly, in some embodiments, the universalgateway device 112 can interface between the local (or internal) networkassociated with the cloud IoT management platform 104 and the othernetwork (e.g., network 110) to provide access to the local (or internal)network associated with the cloud IoT management platform 104 by theother network, and vice versa.

In some embodiments, the universal gateway 112 may create one or morevirtualized devices associated with one or more IoT devices 102 on theother network 110. In some embodiments, the virtualized devices withinthe universal gateway 112 may appear as any other local devices 106associated with the cloud IoT management platform 104, such that acontroller or other device on the cloud IoT management platform 104 cansimply interact with the virtual devices without requiring additionalprogramming or configurations. In various embodiments, the virtualdevices within the universal gateway 112 may be a composition ordecomposition of the associated one or more IoT devices 102, such thatadditional intelligence can be added to the virtual devices prior tobeing presented over the local (or internal) network. For example, insome embodiments, a virtual device may be created to correspond to morethan one IoT device 102, or to include data points from more than oneIoT device 102. In another example, a virtual device may be created tocorrespond to less than all of the data points provided by a particularIoT device 102 or by more than one IoT device 102.

In some embodiments, the universal gateway 112 may generate, organize,or group virtual devices based on a common relationship between two ormore IoT devices 102. For example, if the common relationship betweentwo or more IoT devices 102 is a common space (e.g., room, floor,building, or the like), the universal gateway 112 may rationalize thecommon space relationship between the IoT devices 102 from thecorresponding virtual devices, in order to intelligently group devicesfor organized visibility and control. For example, in some embodiments,the universal gateway 112 may leverage the common space relationshipbetween the IoT devices 102 to group one or more virtual devicesassociated with the group of IoT devices 102 having the common spacerelationship. In another embodiment, the universal gateway 112 maygenerate one or more virtual devices that include one or more datapoints from each of the IoT devices 102 from the group having the commonspace relationship. Accordingly, data and controls associated with thegroup of IoT devices 102 having the common space relationship may behandled by the corresponding group of one or more virtual devices.

For example, still referring to FIG. 1 , the cloud IoT managementplatform 104 may communicate with one or more local devices 106 and/orone or more connected services 108 over the local (or internal) networkassociated with the cloud IoT management platform 104. For example, inone embodiment, the local (or internal) network may be a BuildingAutomation Control Network (“BACnet”), such as a Master Slave TokenPassing (MSTP) BACnet network, a BACnetIP network, or any other suitablenetwork or combination of networks. In other examples, the local (orinternal) network may be any other suitable network, such as a localarea network (LAN), a wireless local area network (WLAN), a campus areanetwork (CAN), an EthernetIP network, or any other suitable network forcontrolling or communicating with the local devices 106 and/or theconnected services 108 associated with the cloud IoT management platform104.

In some embodiments, the local devices 106 may include any suitabledevice associated with the cloud IoT management platform 104, such asbuilding equipment and devices. Example building equipment and devicesmay include air handling units (AHUs), variable air volume units (VAVs),rooftop air handling units (RTUs), controllers, actuators, chillers,sensors, security devices, access control devices, occupancy sensors,thermostats, lighting devices, audio/visual devices, and/or the like. Inother examples, the local devices 106 may include any suitable IoTdevices, as described above. In still other examples, the local devices106 may include one or more human-machine interfaces or clientinterfaces (e.g., graphical user interfaces, reporting interfaces,text-based computer interfaces, client-facing web services, web serversthat provide pages to web clients, and/or the like) for controlling,viewing, or otherwise interacting with the IoT environment 100, IoTdevices 102, connected services 108, and/or the cloud IoT managementplatform 104. For example, the local devices 106 may include a computerworkstation, a client terminal, a remote or local interface, astationary terminal, a mobile device, and/or any other type of userinterface device. For example, the local devices 106 may include adesktop computer, a computer server with a user interface, a laptopcomputer, a tablet, a smartphone, a PDA, or any other type of mobile ornon-mobile device. The local devices 106 communicate with the cloud IoTmanagement platform 104 and/or the connected services 108 over the local(or internal) network. In some embodiments, the connected services 108may include one or more cloud-based services that can be accessed viathe local (or internal) network. Example connected services 108 mayinclude data analysis programs, cloud-based knowledgebases, or othersuitable services. In some embodiments, the connected services 108 mayinclude services allowing for a user to remotely access and interfacethe cloud IoT management platform 104, the local devices 106, and/or theIoT devices 102.

In some embodiments, the network 110, may provide communication betweenone or more IoT devices 102 and the cloud IoT management platform 104.Thus, the IoT devices 102 may be “non-local” (or “foreign”) systems ordevices with respect to the cloud IoT management platform 104. As usedherein, the term “non-local” or “foreign” system or device is used todescribe devices that do not natively communicate with the IoTmanagement platform 104 via the local (or internal) network. Forexample, in some embodiments, the IoT devices 102 may communicate overone or more protocols that are different from those used by the cloudIoT management platform 104. Thus, the non-local devices and/or systems(e.g., the IoT devices 102) may require additional devices or softwareto interface with the local (or internal) network associated with thecloud IoT management platform 104.

In some embodiments, the network 110 may include one or more proprietarynetworks associated with the IoT devices and systems 102. In otherexamples, the network 110 may include a commonly used communicationprotocol that is distinct from that being used for the local (orinternal) network of the cloud IoT management platform 104. For example,the network 110 may utilize an Internet protocol (IP), a transmissioncontrol protocol (e.g., TCP/IP), a user datagram protocol (UDP), aHyperText Transfer protocol (HTTP), an Internet Layer protocol (e.g.,IPv6), a Bluetooth protocol, a ZigBee protocol, a Z-Wave protocol, a6LowPAN protocol, a Thread protocol, a Sigfox protocol, a Neul protocol,a LoRaWAN protocol, a cellular protocol, and/or other suitable protocolsthat are different from that used by the local (or internal) network ofthe cloud IoT management platform 104.

In some embodiments, the universal gateway 112 is configured to providean interface between the local (or internal) network associated with thecloud IoT management platform 104 and the non-local network (e.g.,network 110). For example, the universal gateway 112 may convert datatransmitted over the network 110 into a compatible network protocol usedby the cloud IoT management platform 104 (e.g., BACnet, LAN, WLAN, CAN,and/or the like) for use with the local (or internal) network. In oneembodiment, the universal gateway 112 can read and write data to boththe local (or internal) network and the non-local network (e.g., network110). In some embodiments, the universal gateway 112 may further have awireless radio for communicating with one or more user devices, such asmobile device. In some embodiments, a user accesses the universalgateway 112 via the user device, allowing the user access to thenon-local network (e.g., network 110) and/or the local (or internal)network associated with the cloud IoT management platform 104. Theuniversal gateway 112 will be described in further detail below.

In some embodiments, the cloud IoT management platform 104 generatesdata internally. For example, cloud IoT management platform 104 mayinclude a web advertising system, a website traffic monitoring system, aweb sales system, and/or other types of platform services that generatedata. The data generated by cloud IoT management platform 104 can becollected, stored, and processed along with the data received from otherdata sources (e.g., the IoT devices 102, the local devices 106, and/orthe like). In some embodiments, the cloud IoT management platform 104can collect data directly from external systems or devices, via thelocal (or internal) network, and/or via the network 110. In variousembodiments, the cloud IoT management platform 104 can process andtransform the collected data, and may generate recommendations, controloperations, alerts, notices, and/or the like based on the collecteddata. In some embodiments, the cloud IoT management platform 104 maylearn from the collected data (e.g., via machine learning or datamining) to provide operational efficiencies for the IoT environment 100.

Cloud IoT Management Platform

Referring now to FIG. 2 , a block diagram of a cloud IoT managementsystem (IoTMS) 200 is shown, according to some embodiments. IoTMS 200can be implemented in an IoT environment to automatically monitor andcontrol various device functions. IoTMS 200 is shown to include a cloudIoT controller 266 and the universal gateway 112. In some embodiments,the cloud IoT controller 266 may correspond to a controller for thecloud IoT management platform 104 as described with reference to FIG. 1. In some embodiments, the universal gateway 112 is configured toprovide an interface between IoT devices 102 and the cloud IoTmanagement system 200, as described above. The IoT devices 102 are shownto include a plurality of IoT devices. However, the number of IoTdevices is not limited to those shown in FIG. 2 . Each of the IoTdevices 102 may include any suitable device having network connectivity,such as, those discussed above with reference to FIG. 1 . For example,in some embodiments, the IoT devices 102 may include a mobile phone,laptop, tablet, smart speaker, vehicle, appliance, light fixture,thermostat, wearable, medical implant, equipment, sensor, and/or thelike. Further, each of the IoT devices 102 can include any number ofdevices, controllers, and connections for completing its individualfunctions and control activities. For example, any of the IoT devices102 can be a system or subsystem of devices in itself includingcontrollers, equipment, sensors, and/or the like.

cloud IoT controller 266 can include one or more computer systems (e.g.,servers, supervisory controllers, subsystem controllers, etc.) thatserve as system level controllers, application or data servers, headnodes, or master controllers of the IoT devices 102 and/or othercontrollable systems or devices in an IoT environment. cloud IoTcontroller 266 may include a communications interface 207 to communicatewith multiple downstream IoT devices 102 and/or systems via theuniversal gateway 112 according to like or various disparate protocols,for example, such as one or more of the protocols discussed above withreference to FIG. 1 .

In some embodiments, the IoT devices 102 receive information from cloudIoT controller 266 (e.g., commands, setpoints, operating boundaries,etc.) and provides data to cloud IoT controller 266 (e.g., measurements,valve or actuator positions, operating statuses, diagnostics, etc.) viathe universal gateway 112. For example, the IoT devices 102 may providethe universal gateway 112 with data generated or otherwise collected bythe IoT devices 102, for example, such as measurements from varioussensors, equipment on/off states, equipment operating capacities, and/orany other information, that can be used by cloud IoT controller 266 tomonitor or control a variable state or condition within the IoTenvironment, and the universal gateway 112 may provide the data to theIoT controller 266 for processing and analysis. In some embodiments, theuniversal gateway 112 may receive the data from the IoT devices 102 overa first protocol, and may provide the data to the IoT controller 266over a second protocol different from the first protocol, and viceversa. The universal gateway 112 will be described in more detail withreference to FIGS. 3-8 .

Still referring to FIG. 2 , cloud IoT controller 266 is shown to includea communications interface 207 and an internal (or local) networkinterface 209. Interface 207 may facilitate communications between cloudIoT controller 266 and the IoT devices 102. Internal network interface209 may facilitate communications between cloud IoT controller 266 andconnected services 244 for allowing user control, monitoring, andadjustment to cloud IoT controller 266, IoT devices 102, or localdevices 106. Interface 209 may also facilitate communications betweencloud IoT controller 266 and local devices 106. As discussed above, onedifference between the local devices 106 and IoT devices 102 is that thelocal devices 106 communicate with the cloud IoT controller 266 using acommon or the same protocol, whereas the IoT devices 102 communicatewith the cloud IoT controller 266 using one or more disparate protocols.In various embodiments, interfaces 207 and 209 may be the sameinterface, or may be separate interfaces.

Interfaces 207 and 209 can be or include wired or wirelesscommunications interfaces (e.g., jacks, antennas, transmitters,receivers, transceivers, wire terminals, etc.) for conducting datacommunications with IoT devices 102, local devices 106, connectedservices 108, and/or other internal or external systems or devices. Invarious embodiments, communications via interfaces 207 and 209 can bedirect (e.g., local wired or wireless communications) or via acommunications network 110 (e.g., a WAN, the Internet, a cellularnetwork, etc.). For example, interfaces 207 and 209 can include anEthernet card and port for sending and receiving data via anEthernet-based communications link or network. In another example,interfaces 207 and 209 can include a Wi-Fi transceiver for communicatingvia a wireless communications network. In another example, one or bothof interfaces 207 and 209 can include cellular or mobile phonecommunications transceivers.

Still referring to FIG. 2 , in various embodiments, cloud IoT controller266 is implemented using a distributed or cloud computing environmentwith a plurality of processors and memory. That is, cloud IoT controller266 can be distributed across multiple servers or computers (e.g., thatcan exist in distributed locations). For convenience of description,cloud IoT controller 266 is shown as including at least one processingcircuit 204 including a processor 206 and memory 208. Processing circuit204 can be communicably connected to communications interface 207 and/orinternal network interface 209 such that processing circuit 204 and thevarious components thereof can send and receive data via interfaces 207and 209. Processor 206 can be implemented as a general purposeprocessor, an application specific integrated circuit (ASIC), one ormore field programmable gate arrays (FPGAs), a group of processingcomponents, or other suitable electronic processing components.

Memory 208 (e.g., memory, memory unit, storage device, etc.) can includeone or more devices (e.g., RAM, ROM, Flash memory, hard disk storage,etc.) for storing data and/or computer code for completing orfacilitating the various processes, layers and modules described in thepresent application. Memory 208 can be or include volatile memory ornon-volatile memory. Memory 208 can include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures described in the present application. According to someembodiments, memory 208 is communicably connected to processor 206 viaprocessing circuit 204 and includes computer code for executing (e.g.,by processing circuit 204 and/or processor 206) one or more processesdescribed herein.

However, the present disclosure is not limited thereto, and in someembodiments, cloud IoT controller 266 can be implemented within a singlecomputer (e.g., one server, one housing, etc.). Further, while FIG. 2shows monitoring and reporting applications 222 and enterprise controlapplications 226 as existing outside of cloud IoT controller 266, insome embodiments, applications 222 and 226 can be hosted within cloudIoT controller 266 (e.g., within memory 208).

Still referring to FIG. 2 , memory 208 is shown to include an enterpriseintegration layer 210, an automated measurement and validation (AM&V)layer 212, a fault detection and diagnostics (FDD) layer 216, anintegrated control layer 218, and an IoT device integration later 220.Layers 210-220 can be configured to receive inputs from IoT deices 228and other data sources, determine optimal control actions for the IoTdevices 228 based on the inputs, generate control signals based on theoptimal control actions, and provide the generated control signals toIoT devices 228.

Enterprise integration layer 210 can be configured to serve clients orlocal applications with information and services to support a variety ofenterprise-level applications. For example, enterprise controlapplications 226 can be configured to provide subsystem-spanning controlto a graphical user interface (GUI) or to any number of enterprise-levelbusiness applications (e.g., accounting systems, user identificationsystems, etc.). Enterprise control applications 226 may also oralternatively be configured to provide configuration GUIs forconfiguring cloud IoT controller 266. In yet other embodiments,enterprise control applications 226 can work with layers 210-220 tooptimize the IoT environment based on inputs received at interface 207and/or interface 209.

Device integration layer 220 can be configured to manage communicationsbetween cloud IoT controller 266 and the IoT devices 102 and/or localdevices 106. For example, device integration layer 220 may receivesensor data and input signals from the IoT devices 102 via the universalgateway 112, and provide output data and control signals to the IoTdevices 102 via the universal gateway 112. Device integration layer 220may also be configured to manage communications between the IoT devices102, the local devices 106, and/or between the IoT devices 102 and thelocal devices 106. In some embodiments, device integration layer 220 maytranslate communications (e.g., sensor data, input signals, outputsignals, etc.) across a plurality of multi-vendor/multi-protocolsystems.

Integrated control layer 218 can be configured to use the data input oroutput of device integration layer 220 to make control decisions. Forexample, in some embodiments, due to the device integration provided bythe device integration layer 220, integrated control layer 218 canintegrate control activities of the IoT devices 102 such that the IoTdevices 102 behave as a single integrated supersystem. In someembodiments, integrated control layer 218 includes control logic thatuses inputs and outputs from a plurality of IoT device subsystems toprovide insights that separate IoT device subsystems could not providealone. For example, integrated control layer 218 can be configured touse an input from a first IoT device subsystem to make a controldecision for a second IoT device subsystem. Results of these decisionscan be communicated back to device integration layer 220.

Automated measurement and validation (AM&V) layer 212 can be configuredto verify that control strategies commanded by integrated control layer218 are working properly (e.g., using data aggregated by AM&V layer 212,integrated control layer 218, device integration layer 220, FDD layer216, and/or the like). The calculations made by AM&V layer 212 can bebased on IoT device data models and/or equipment models for individualIoT devices or subsystems. For example, AM&V layer 212 may compare amodel-predicted output with an actual output from IoT devices 102 todetermine an accuracy of the model.

Fault detection and diagnostics (FDD) layer 216 can be configured toprovide on-going fault detection for the IoT devices 102, local devices106, and subsystem devices (equipment, sensors, and the like), andcontrol algorithms used by integrated control layer 218. FDD layer 216may receive data inputs from integrated control layer 218, directly fromone or more IoT devices or subsystems 102, or from another data source.FDD layer 216 may automatically diagnose and respond to detected faults.The responses to detected or diagnosed faults can include providing analert message to a user, a maintenance scheduling system, or a controlalgorithm configured to attempt to repair the fault or to work-aroundthe fault.

FDD layer 216 can be configured to output a specific identification ofthe faulty component or cause of the fault (e.g., faulty device orsensor) using detailed subsystem inputs available at device integrationlayer 220. In other exemplary embodiments, FDD layer 216 is configuredto provide “fault” events to integrated control layer 218 which executescontrol strategies and policies in response to the received faultevents. According to some embodiments, FDD layer 216 (or a policyexecuted by an integrated control engine or business rules engine) mayshut-down IoT systems, devices, and/or or components or direct controlactivities around faulty IoT systems, devices, and/or components toreduce waste, extend IoT device life, or to assure proper controlresponse.

FDD layer 216 can be configured to store or access a variety ofdifferent system data stores (or data points for live data). FDD layer216 may use some content of the data stores to identify faults at theIoT device or equipment level and other content to identify faults atcomponent or subsystem levels. For example, the IoT devices 102 maygenerate temporal (i.e., time-series) data indicating the performance ofIoTMS 200 and the various components thereof. The data generated by theIoT devices 102 can include measured or calculated values that exhibitstatistical characteristics and provide information about how thecorresponding system or IoT application process is performing in termsof error from its setpoint. These processes can be examined by FDD layer216 to expose when the system begins to degrade in performance and alerta user to repair the fault before it becomes more severe.

Universal Gateway

The IoT management system 200 (or platform 104), as described above,operate over a local (or internal) network associated with the system200. In some embodiments, one or more other networks may be used tocommunicate with the system 200, which are not compatible with the local(or internal) network. As described below, a universal gateway devicecan interface between the local (or internal) network and the othernetworks to provide access to the other networks by the local (orinternal) network, and vice versa. In some embodiments, the universalgateway may generate one or more virtualized devices associated with oneor more third-party devices (e.g., the IoT devices 102) on the othernetworks. In some embodiments, the virtualized devices within theuniversal gateway can be configured to appear as devices associated withthe local (or internal) network such that a controller or other deviceson the system 200 interacts with the virtual devices without requiringadditional programming or configurations.

For example, referring now to FIG. 3 , an example of a universal gatewayis shown in more detail, according to some embodiments. In variousembodiments, universal gateway 112 may be a part of cloud IoT controller266 (e.g., a part of communications interface 207) or may be a separatedevice. In some embodiments, universal gateway 112 may be implementedusing a distributed or cloud computing environment with a plurality ofprocessors and memory. That is, universal gateway 112 can be distributedacross multiple servers or computers (e.g., that can exist indistributed locations). In other embodiments, universal gateway 112 maybe implemented on a single or dedicated computing environment (e.g., oneor more server systems).

In some embodiments, the universal gateway 112 includes an internalnetwork interface circuit 300 for communicating with an internal network(e.g., local network associated with the system 200) and an externalnetwork interface circuit 302 for communicating with one or moreexternal networks (e.g., non-local networks such as the network 110).The internal network interface circuit 300 includes a processing circuit304. The processing circuit 304 includes a processor 306 and memory 308.The processor 306 may be a general purpose or specific purposeprocessor, an application specific integrated circuit (ASIC), one ormore field programmable gate arrays (FPGAs), a group of processingcomponents, or other suitable processing components. The processor 306may be configured to execute computer code or instructions stored in thememory 308 or received from other computer readable media (e.g., CDROM,network storage, a remote server, etc.).

The memory 308 may include one or more devices (e.g., memory units,memory devices, storage devices, etc.) for storing data and/or computercode for completing and/or facilitating the various processes describedin the present disclosure. The memory 308 may include random accessmemory (RAM), read-only memory (ROM), hard drive storage, temporarystorage, non-volatile memory, flash memory, optical memory, or any othersuitable memory for storing software objects and/or computerinstructions. The memory 308 may include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures described in the present disclosure. The memory 308 may becommunicably connected to the processor 306 via processing circuit 304and may include computer code for executing (e.g., by processor 306) oneor more processes described herein.

The memory 308 is shown to include a gateway executable module 310, avirtual network simulation module 312, and a webserver 314. The gatewayexecutable module 310 includes the software modules required foroperating the non-virtualized portion of the universal gateway 112. Thegateway executable module 310 will be described in more detail below.The virtual network simulation module 312 includes the software modulesrequired for operating the virtualized portion of the universal gateway112, and will be described in more detail below.

The webserver 314 is configured to process and deliver web pages to auser. In one embodiment, the webserver 314 may be an HTTP webserver. Thewebserver 314 may be configured to deliver images, such as HTMLdocuments to a user via a user device (e.g., a mobile device) associatedwith the user. The webserver 314 may support server-side scripting,Active Server Pages, or other scripting languages. The webserver 314 mayfurther be configured to provide information or generate web-pages todevices in a local network. For example, the webserver 314 may beconfigured to provide web-pages to devices which are connected directlyto the universal gateway 112, such as via wireless radio 316. In someembodiments, the webserver 314 can provide a web-portal for a user toaccess the universal gateway 112. In some embodiments, the user canaccess the universal gateway 112 via the user device by accessing theweb-portal (e.g. website) generated by the webserver 314. In someembodiments, the web-portal provides basic information associated withthe universal gateway 112, such as configuration data, network data,status, errors, etc. In further embodiments, the web-portal may allowthe user to fully configure the universal gateway 112 via the userdevice. For example, the user may be able to connect the universalgateway 112 to both the local (or internal) network associated with thesystem 200 and the non-local network (e.g., network 110) via theweb-portal. In still further embodiments, the user may be able toconfigure the one or more devices (e.g., the IoT devices 102) associatedwith the non-local network (e.g., network 110) via the web-portal. Thiscan allow a user to quickly and easily configure the universal gateway112 to provide the interface between the local (or internal) network andthe non-local network 110.

In one embodiment, the internal network interface circuit 300 includes awireless radio 316. In one embodiment, the wireless radio 316 is a Wi-Firadio. The Wi-Fi radio can be configured to utilize service setidentifier (“SSID”) technology. SSID technology can be used such thatonly devices with specific access to the SSID associated with theuniversal gateway 112 will be allowed to access the data associated withthe universal gateway 112 via the webserver 314. In other embodiments,the wireless radio 316 can be configured to utilize other securitylayers to restrict access to the universal gateway 112. For example, auser attempting to access the universal gateway 112 via the wirelessradio 316 may be required to provide a user name and password beforebeing allowed access. In still further examples, the user may berequired to maintain an identity token on the user device used to accessthe universal gateway 112 via the wireless radio 316, such that the useris required to present the token to the universal gateway 112 to obtainaccess. While the wireless radio 316 is described above in relation to aWi-Fi radio, the wireless radio 316 may utilize other wirelesscommunication protocols, for example, such as Wi-Max, ZigBee, LoRA,Bluetooth, NFC, cellular (3G, 4G, LTE, CDMA), RF, IR, or other suitablewireless communication protocols.

The internal network interface circuit 300 further includes acommunication interface 318. The communication interface 318 isconfigured to communicate with a second communication interface 320located on the external network interface circuit 302. In oneembodiment, the communication interfaces 318, 320 are serialcommunication interfaces, such as USB. In other examples, thecommunication interfaces 318, 320 may be other suitable kinds of serialinterfaces, for example, such as RS-232, RS-485, or other suitableserial communication interfaces. The internal network interface circuit300 may further include an internal network interface 322. The internalnetwork interface 322 can provide communication to and from the local(or internal) network associated with system 200. For example, theinternal network interface 322 may be a BACnet interface, a LANinterface, a WLAN interface, a CAN interface, an EthernetIP networkinterface, or any other suitable network interface.

The external network interface circuit 302 can also include a processingcircuit 324. The processing circuit 324 is in communication with thecommunication interface 320 for communicating with the internal networkinterface circuit 300. The processing circuit 324 includes a processor326 and memory 328. The processor 326 may be a general purpose orspecific purpose processor, an application specific integrated circuit(ASIC), one or more field programmable gate arrays (FPGAs), a group ofprocessing components, or other suitable processing components. Theprocessor 326 may be configured to execute computer code or instructionsstored in the memory 328 or received from other computer readable media(e.g., CDROM, network storage, a remote server, etc.). In someembodiments, processing circuits 304 and 324 can be the same processingcircuit.

The memory 328 may include one or more devices (e.g., memory units,memory devices, storage devices, etc.) for storing data and/or computercode for completing and/or facilitating the various processes describedin the present disclosure. The memory 328 may include random accessmemory (RAM), read-only memory (ROM), hard drive storage, temporarystorage, non-volatile memory, flash memory, optical memory, or any othersuitable memory for storing software objects and/or computerinstructions. The memory 328 may include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures described in the present disclosure. The memory 328 may becommunicably connected to the processor 326 via processing circuit 324and may include computer code for executing (e.g., by processor 326) oneor more processes described herein.

The memory 328 may include a device data module 330. The device datamodule 330 may be used to store data related to devices (e.g., IoTdevices 102) associated with the external network (e.g., non-localnetwork such as network 110). Example data may include data points,device address, device names, device types, device status, data pointvalues, and/or the like. In one embodiment, the external networkinterface circuit 302 is configured to interface with the externalnetwork. The external network interface circuit 302 may interface withthe external network (or non-local network) via an external networkinterface 332. In some embodiments, the external network interfacecircuit 302 may further include a level converter 334. The levelconverter 334 may be used where the signal levels on the externalnetwork (or non-local network) are not compatible with the processingcircuit 324. In some embodiments, the level converter 334 is integral tothe external network interface 332. In examples where the externalnetwork interface circuit 302 has a level converter 334, the levelconverter 334 may provide communication between the processing circuit324 and the external network interface 332. In other embodiments wherethe level converter 334 is not used, the processing circuit 324interacts directly with the external network interface 332 to access theexternal network (or non-local network).

Referring now to FIG. 4 an interface diagram showing an interactionbetween the gateway executable module 310 and the virtual networksimulation module 312 of the internal network interface circuit in FIG.3 is shown, according to some embodiments. As shown in FIG. 4 , thegateway executable module 310 can include a data access component 400,an application layer (ORE) 402, a network layer (protocol engine) 404,an IP datalink layer 406, and a virtual datalink layer 408. The virtualnetwork simulation module 312 is shown to include a first virtual device410 and a second virtual device 412. While only two virtual devices 410and 412 are shown, it is contemplated that multiple virtual devices maybe located within the virtual simulation module 312, each correspondingto one or more of the IoT devices 102. For example, in one embodiment,the virtual network simulation module 312 may include up to two-hundredvirtual devices. However, in other embodiments, the virtual networksimulation module 312 may include more than two-hundred virtual devicesor less than two-hundred virtual devices. The virtual network simulationmodule 312 may further include a virtual application layer (ORE) 414, avirtual network layer 416, an external network interface circuitintegration module 418, a communication driver 420, and a virtualdatalink layer 422.

The data access component 400 of the gateway executable module 310 isconfigured to access data within the virtual devices 410 and 412 in thevirtual network simulation module 312. In one embodiment, the dataaccess component 400 is configured to store one or more poll mappersthat are configured to poll the virtual devices 410 and 412 to obtainthe desired data. The data access component 400 may further beconfigured to communicate the data from the virtual devices 410 and 412to the application layer (ORE) 402. In one example, the data accesscomponent 400 is a Multi-Touch Gateway UI Data Access Component. Inother embodiments, the data access component 400 is a Mobile AccessPortal. However, other data access component types are contemplated aswell. In some embodiments, the data access component is configured tointerface with the one or more virtual devices 410 and 412.

The application layer (ORE) 402 may be configured to convert datareceived from the data access component 400 into data readable by thedevices and systems (e.g., the cloud IoT control 266, the local devices106, and/or the like) associated with the local (or internal) network ofsystem 200. The network layer 404 may convert the data from the virtualdevices 410 and 412 into a format for use on the local (or internal)network. For example, in the case where the local (or internal) networkis BACnet network, the network layer 404 may map the data from thevirtual devices 410 and 412 into one or more device objects as BACnetreadable data objects. The BACnet data objects may then be configuredsuch that they are readable and/or writable by devices associated withthe local (or internal) network. Further, the network layer 404 may beconfigured to map data received from the local (or internal) network tothe one or more virtual devices 410 and 412. The data mapped to the oneor more virtual devices 410 and 412 can then be passed on to theassociated non-local devices (e.g., IoT devices 102).

The network layer 404 can modify the data stored in the one or morevirtual devices 410 and 412 to be presented over the local (or internal)network. For example, in some embodiments, the network layer 404modifies the data stored in the virtual devices 410 and 412 fortransmission over the local (or internal network) using one or moresuitable protocols (e.g., such as those described with reference toFIGS. 1-3 ) associated with the local (or internal) network. Similarly,the network layer 404 can convert data received via the local (orinternal network) into data that can be mapped to the one or morevirtual devices 410 and 412. The IP datalink layer 406 is configured toaccess an IP based network. For example, where the local (or internal)network is an IP based network (e.g., TCP/IP, BACnet/IP, and/or thelike), the IP datalink layer 406 may package and transmit the datamodified by the network layer 404 over the IP based network. The virtualdatalink layer 408 may be configured to receive and transmit data to thevirtual network simulation module 312. In one embodiment, the virtualdatalink layer 408 communicates with the virtual network simulationmodule 312 via the virtual data link layer 422.

The virtual network simulation module 312 may communicate with theexternal network (e.g., the non-local network 110) via the communicationdriver 420. In one embodiment, the communication driver 420 is a USBdriver for communicating with the external network interface circuit302. In other examples, the communication driver 420 may be other typesof serial data drivers, such as RS-232, RS-485, and/or the like. In someexamples, the communication driver 420 may be a proprietary serialcommunication driver, for example, such as an H-Link communicationdriver from Hitachi. In some embodiments, the communication driver 420can be in communication with the communication interface 318 forcommunicating with the communication interface 320 of the externalnetwork interface circuit 302. The communication driver 420 is furtherin communication with the external network interface circuit integrationmodule 418. The external network interface circuit integration module418 is configured to translate the data from the external networkinterface circuit 302, for use in the virtual network simulation module312. For example, the external network interface circuit integrationmodule 418 may be configured to parse the data received via thecommunication driver 420 into various data points (e.g., individual datapoints). For example, in various embodiments, the external networkinterface circuit integration module 418 may parse the received data bydata type, device type, device address, and/or the like. The externalnetwork interface circuit integration module 418 can then provide theparsed data to the virtual application layer 414.

In some embodiments, the virtual application layer 414 may include avirtual network manager 426. In one embodiment, the virtual networkmanager 426 is responsible for creation and management of virtualdevices 410 and 412, as well as read and write operations to and fromthe virtual devices 410 and 412. In some embodiments, the virtualnetwork manager 426 may be configured to create a virtual network basedon the data received from the external network interface circuitintegration module 418. For example, if the external network interfacecircuit integration module 418 provides data from multiple non-localdevices or systems (e.g., IoT devices 102), the virtual network manager426 can create virtual devices associated with the received data. Forexample, the virtual devices 410 and 412 may be created by the virtualnetwork manager 426, as will be described in more detail below. Thevirtual application layer 414 can further take the data provided by theexternal network interface circuit integration module 418, and workingwith the virtual network manager 426, modify the received data to becompatible with the local (or internal) network associated with system200. For example, by populating the virtual devices 410 and 412 withdata objects, the virtual devices 410 and 412 can be read by the networklayer 404 as individual devices, similar to the local devices 106 on thelocal (or internal) network. An example virtual device is illustrated inFIG. 5 , and will be discussed in greater detail below.

In some embodiments, the virtual application layer 414 can be configuredto map the received data into a virtual device table 428. In oneembodiment, the virtual device table 428 may be populated with datarelated to one or more of the virtual devices 410 and 412. In oneembodiment, the virtual device table 428 may be configured to representa list of virtual objects, such as virtual BACnet objects, but otherdata object types are contemplated. In one embodiment, the virtualdevice table 428 is modified for each virtual device 410 and 412 createdby the virtual network manager 426. The virtual device table 428 mayfurther provide mapping between the virtual devices 410 and 412 and theassociated non-local devices (e.g., the IoT devices 102).

In some embodiments, the virtual network layer 416 is configured tomodify the data stored in the one or more virtual devices 410 and 412 tobe presented over the local (or internal) network. In one embodiment,the virtual network layer 416 modifies the data stored in the virtualdata objects represented by the virtual devices table 428 fortransmission over the local (or internal) network using one or moresuitable protocols that are used by the local (or internal) network, forexample, such as any of those discussed above with reference to FIGS.1-3 . However, other network protocols are also contemplated. Thevirtual datalink layer 422 may be configured to receive and transmitdata to the gateway executable module 310. For example, in oneembodiment, the virtual datalink layer 422 communicates with the gatewayexecutable module 310 via the virtual data link layer 408.

Turning now to FIG. 5 a detailed view of a virtual device 500 is shown,according to some embodiments. In some embodiments, the virtual device500 may be similar to or the same as any one of the virtual devices 410and 412 described above. For example, in some embodiments, the virtualdevice 400 is a virtual representation of a non-local or foreign device(e.g., an IoT device 102) presented as a local device 106 to the local(or internal) network associated with the cloud IoT management platform104. In some embodiments, the virtual device 500 is generated by thevirtual network manager 426 based on data received via the externalnetwork (e.g., the non-local network 110) associated with the non-localdevices (e.g., the IoT devices 102). In some embodiments, the virtualdevice 500 includes a number of data points corresponding to actual datapoints of the non-local devices or systems (e.g., the IoT devices 102).For example, in one embodiment, the virtual device 500 includes a devicetype data point 502. In some embodiments, the device type data point 502may include data corresponding to a type of device that the virtualdevice 500 is representing. For example, the device type data point 502may indicate that the virtual device 500 represents a particular type ofIoT device 102, various examples of which are discussed with referenceto FIGS. 1-4 .

In some embodiments, the virtual device 500 may further include variousother data points. For example, the other data points may include binaryoutput data points 504, binary input data points 506, analog output datapoints 508, analog input data points 510, multi-state outputs 512,multi-state inputs 514, and/or the like. However, the present disclosureis not limited thereto, and additional, fewer, or other data points arecontemplated that may be associated with the virtual device 500depending on the type of non-local or foreign device (e.g., IoT device102) that the virtual device 500 is representing. Further, while FIG. 5shows that the virtual device 500 is generated to include multiple datapoints from a single non-local or foreign device (e.g., IoT device 102),the present disclosure is not limited thereto, and in variousembodiments, the virtual device 500 may include less than all datapoints from the single non-local or foreign device, a combination ofdata points from multiple non-local or foreign devices, a combination ofdata points from non-local and local devices, a logical combination ofdata points from various devices having a common relationship, and/orthe like.

For a non-limiting example, as shown in FIG. 5 , the virtual device 500may represent an activity tracker, such as a smart pedometer. In thiscase, in some non-limiting examples, the binary output data points 504may include binary data points such as a (step) count reset 516, arun-stop signal 518, and a prohibit RC operation signal 520. In somenon-limiting examples, the binary input data points 506 may includebinary input data points such as a run/stop input 522, a (step) countreset 524, a communication state 526, an alarm signal 528, and aprohibit operation input 530. In some non-limiting examples, the analogoutput data points 508 may include a current step count data point 532.In some non-limiting examples, the analog input data points 510 mayinclude a step count intake input 534 and a target daily step countinput 536. In some non-limiting examples, the multi-state output datapoints 512 may include an operation mode output 538 and a displaysetting output 540. In some non-limiting examples, the multi-state inputdata points 514 may include data points such as an operation mode stateinput 542, an alarm code 544, and a display setting input 546. It shouldbe understood that the above described data points are provided only asan example in the context of a smart pedometer, and thus, other datapoints are contemplated depending on the type of device.

In some embodiments, the virtual device 500 may further include avirtual network manager interface 548. The virtual network managerinterface 548 is configured to interface with the virtual networkmanager 426. The virtual network manager interface 548 can receive datapoint values, device type information, device status information, andother information related to an associated non-local or foreign device(e.g., IoT device 102) via the virtual network manager 426. In someembodiments, the virtual network manager interface 548 is configured tocommunicate values received via the data access component 400 to thevirtual network manager 426. The virtual network manager interface 548can then provide the new values to the associated non-local or foreigndevice. In some embodiments, the virtual network manager interface 548emulates multiple network devices based on devices listed the virtualdevice table 428. For example, in some embodiments, a ‘Who-Is’ requestmay be answered with an ‘I Am’ response from multiple network deviceswith unique virtual MAC addresses. In some embodiments, the virtualnetwork manager interface 548 can emulate the non-local or foreigndevices listed in the virtual device table 428 as one of the localdevices 106.

Turning now to FIG. 6 , a process 600 for interfacing with an externalnetwork using the universal gateway 112 is shown, according to someembodiments. At process block 602, the external network interfacecircuit 302 is initialized. At process block 604, the external networkinterface circuit 302 communicates with the non-local or foreign network(e.g., network 110) to discover all devices and/or subsystems on thenon-local network 110. In one example, the external network interfacecircuit 302 communicates with the non-local network 110 via the externalnetwork interface 332. At process block 606, the data from thediscovered devices is organized into data structures 329 by the externalnetwork interface circuit 302. In one embodiment, the data structures329 may be stored in one or more data tables, for example, such as datastructures 329. In one embodiment, the data tables are stored in thedevice data module 330. The data tables may be configured to store datastructures 329 for each discovered non-local or foreign device (e.g.,IoT device 102). The data structures 329 can be unique to eachdiscovered device. In some embodiments, the data structures 329 may bepartially constructed by the processing circuit 324 of the externalnetwork interface circuit 302. For example, the data structures 329 maybe partially constructed based on the detected device type. By receivingthe device type, a data structure 329 can be constructed by theprocessing circuit 324 to reflect the usual message content receivedfrom the device. In some embodiments, the device data may includemetadata identifying the current running state and any configurationsettings used by the non-local or foreign device (e.g., IoT device 102).The data structures 329 may be formatted to provide for easierconsumption by devices associated with the local (or internal) networkassociated with the cloud IoT management platform 104 or system 200,such as cloud IoT controller 266 and/or local devices 106. For example,the data structures may be formatted using standard device and pointnames as used in the local (or internal) network (e.g., associated witha protocol or network used by the local network). Additional examplesmay include common or standard graphics or other templates. This canreduce the time required for installation and configuration of devicesand subsystems (e.g., IoT devices 102) associated with the non-local orforeign network 110. Further, by formatting the data structures 329 tobe compatible with the local (or internal) network, non-intelligentdevices (e.g., valves, actuators, and/or the like) can communicate withthe cloud IoT management platform 104 or system 200 via a common datamodel. The common data model may include intelligence that allows one ormore controllers or other local devices 106 to recognize or identifynon-local or foreign devices or subsystems (e.g., IoT devices 102) withminimal effort.

At process block 608, the discovered devices can be polled to obtainvalues for one or more data points associated with the discovereddevices. For example, in one embodiment, the external network interfacecircuit 302 performs the polling. In one embodiment, the polling may beconducted immediately upon the data structures being organized and setupat process block 606. In other embodiments, the polling may be conductedat regular intervals to ensure that the device data is current. In someembodiments, once the discovered devices have been polled, the devicedata structures are updated at process block 610. At process block 612,the external network interface circuit 302 schedules and parses the datato be sent to the internal network interface circuit 300.

Referring now to FIG. 7 , a process 700 for generating one or morevirtual devices is shown, according to some embodiments. At processblock 702, the virtual network manager 426 is notified that a device hasbeen detected on the external network 110. In one embodiment, thenotification is performed by the external network interface circuit 302.In one example, the notification may be in the form of a data packetsent to the virtual network manager 426. In some embodiments, theindication may include an address and/or device type of the newlydiscovered device. Once the notification has been provided to thevirtual network manager 426, data associated with the new device can beprovided to the virtual network manager 426. In one embodiment, the datais provided by the external network interface circuit 302. The data maycontain a unique MAC address associated with the device. Further, thereceived data may include information related to the device type. Forexample, the information related to the device type may indicate whetherthe device is a mobile device or a stationary device. In otherembodiments, the unique MAC address may be associated with the type ofdevice. For example, the prefix or suffix of the MAC address may beassociated with specific device types.

At process block 706, the virtual network manager 426 determines if thedevice is currently listed in the virtual device table 428. For example,in one embodiment, the virtual network manager 426 determines if thereceived unique MAC address is currently listed in the virtual devicetable 428. However, in other embodiments, the virtual network manager426 may evaluate other criteria to determine if the device is listed inthe virtual device table 428, for example, such as a unique deviceidentifier. If the device is a known device (e.g., yes at process block706), the virtual device data objects for the device may be updated withthe received data values at process block 712. On the other hand, if thedevice is not currently listed in the virtual device table 428 (e.g., noat process block 706), the virtual network manager 426 will generate anew virtual device at process block 708. In one embodiment, the virtualnetwork manager 426 may generate the virtual device based on the type ofdevice associated with the device type. In other embodiments, thevirtual network manager 426 may generate the virtual device based on theunique MAC address of the device. In some examples, the virtual networkmanager 426 may have access to a database having data points provided bydifferent data types. The virtual network manager 426 can then utilizethe database to generate virtual devices having the proper data pointsand/or other parameters. In some embodiments, the virtual networkmanager 426 may initially set up the virtual device as an “offline”device. In this case, in some embodiments, the virtual device may remainas an offline device until additional data is received.

At process block 710, data value changes can be received by the virtualnetwork manager 426. In some embodiments, receiving data valuesassociated with the virtual device prompts the virtual network manager426 to configure the virtual device to be “online.” In one embodiment,the virtual network manager 426 passively waits to receive data valuesrelated to the virtual device. In other embodiments, the virtual networkmanager 426 may be configured to request updated data values associatedwith the virtual device from the external network interface circuit 302.At process block 712, the virtual device data objects may be updatedwith the received data values.

Turning now to FIG. 8 , an illustration of an interface process betweenthe external network interface circuit 302 and the virtual networkmanager 426 is shown, according to some embodiments. At process block802, a new device is discovered as described above with reference toFIG. 6 . The external network interface circuit 302 then transmits datapacket 804 to the virtual network manager 426. In one embodiment, thedata packet 804 includes a TYPE data message and an ADDRESS datamessage. However, other data messages are contemplated. The TYPE datamessage may refer to the device type. For example, the TYPE data messagemay indicate whether the detected discovered device is a mobile deviceor a stationary device. In other examples, the TYPE data message mayrelate to a specific device type, such as whether the device is a smartspeaker, smart thermostat, smart car, or the like, for example. TheADDRESS data message may be an address associated with the discovereddevice. In one embodiment, the ADDRESS data message is a unique MACaddress supplied by the external network interface circuit 302. Thevirtual network manager 426 may then receive the data packet 804 andcreate a virtual device at process block 806. In one embodiment, thevirtual network manager 426 creates the virtual device as describedabove with reference to FIG. 7 .

At process block 808 a device value change associated with one or morenon-local or foreign devices (e.g., IoT devices 102) is detected by theexternal network interface circuit 302. The external network interfacecircuit 302 then transmits data packet 810 to the virtual networkmanager 426. In one embodiment, the data packet 810 includes a DEVICEDATA data message and an ADDRESS data message. In one embodiment, theDEVICE DATA data message is a structure containing all of the data whosevalues are determined by the external network interface circuit 302.Accordingly, the DEVICE DATA data message may vary depending on thedevice type it is associated with. The ADDRESS data message may be anaddress associated with the discovered device. In one embodiment, theADDRESS data message is a unique MAC address supplied by the externalnetwork interface circuit 302. The virtual network manager 426 may thenreceive the data packet 810 and update the virtual device at processblock 812. In some embodiments, the virtual network manager 426 may alsomodify the virtual device to indicate that it is “Online” afterreceiving updated data if the virtual device was previously indicated as“Offline.”

At process block 814, a device status update is detected by the externalnetwork interface circuit 302. The external network interface circuit302 then transmits data packet 816 to the virtual network manager 426.In one embodiment, the data packet 816 includes an ADDRESS data message,and OFFLINE data message, and an ERROR data message. The ADDRESS datamessage may be an address associated with the device having a statusupdate. In one embodiment, the ADDRESS data message is a unique MACaddress supplied by the external network interface circuit 302. TheOFFLINE data message may be a binary signal indicating that the devicehas gone offline. In other embodiments, the OFFLINE data message may beany other type of signal indicating that the device has gone offline.The ERROR data message may indicate an error on the device. In someembodiments, the ERROR data message is an enumeration of possible errorconditions for the non-local or foreign device (e.g., IoT device 102).The virtual network manager 426 may then receive the data packet 816 andupdate the virtual device at process block 818. In some embodiments, thevirtual network manager 426 may also modify the virtual device toindicate that it is “Offline.” In some embodiments, the virtual networkmanager 426 may generate a flag to indicate that an error has occurred.

At process block 820, the virtual network manager 426 initiates avirtual device value change request. The value change request mayindicate a desired modification to a parameter of one or more non-localor foreign devices (e.g., IoT devices 102). For example, the virtualnetwork manager 426 may receive a request to change a value of a virtualdevice via the local or internal network, for example, such as from thecloud IoT controller 266, one or more of the local devices 106, and/orthe like. Once the virtual device value change request has beeninitiated at process block 820, the virtual network manager 426 thentransmits a data packet 822 to the external network interface circuit302. In one embodiment, the data packet 822 includes an ADDRESS datamessage and a DEVICE DATA data message. The ADDRESS data message may bean address associated with the virtual device that the virtual networkmanager 426 requires the value to change. In one embodiment, the ADDRESSdata message is a unique MAC address supplied by the external networkinterface circuit 302. In one embodiment, the DEVICE DATA data messageis a structure containing all of the data whose values are to bemodified by the external network interface circuit 302. The externalnetwork interface circuit 302 may then receive the data packet 822 andupdate the associated non-local or foreign device (e.g., IoT device 102)at process block 824.

Referring now to FIG. 9 , a process 900 for exposing virtual devices toa local (or internal) network is shown, according to some embodiments.At process block 902, the gateway executable module 310 detects that oneor more new virtual devices have been generated (or added). In oneembodiment, the gateway executable module 310 may determine that a newvirtual device has been generated by monitoring an active node table(e.g., the virtual device list 428). In one embodiment, the active nodetable may be stored within the memory 308 of the internal networkinterface circuit 300. The active node table may change as new virtualdevices are added to the virtual network via the virtual network manager426. In some embodiments, the virtual network manager 426 is configuredto update the active node table when a new device is added. In otherembodiments, the virtual network manager 426 may provide a signalgateway executable module when a new virtual device is added to thevirtual device list 428.

At process block 904, discovery of the remaining data points arescheduled. In one embodiment, the virtual application layer 414schedules the discovery of the remaining data points. The remaining datapoints may be those data points within the virtual devices 410 and 412that have yet to be received from the field devices (e.g., IoT devices102) associated with the virtual devices. At process block 906, thenetwork layer 404 may read the new virtual devices 410 and 412. Thenetwork layer 404 may receive a signal indicating that the virtualdevices 410 and 412 have been created or that values associated with thevirtual devices 410 and 412 have changed. At process block 908 thevirtual devices 410 and 412 are exposed to the local (or internal)network by the network layer 404. Exposing the virtual devices 410 and412 to the internal network allows for devices or services on theinternal network to see (e.g., discover and/or communicate with) thevirtual devices 410 and 412 as field devices (e.g., local devices 106)associated with the internal network. In some embodiments, the virtualdevices 410 and 412 are configured to appear as standard local devices106 to the internal network.

According to various example embodiments, the universal gateway 112,using the methods described above, may present the non-local or foreigndevices (e.g., IoT devices 102) to the cloud IoT management platform 104or system 200, such that the non-local or foreign devices (e.g., IoTdevices 102) appear the same as any other local device 106 on the local(or internal) network. Similarly, in various embodiments, the universalgateway 112 provides data generated by the non-local or foreign devices(e.g., IoT devices 102) to the cloud IoT management platform 104 orsystem 200, such that the data appears to be generated as it would be byany other local devices 106 on the local (or internal) network. On theother hand, in various embodiments, the universal gateway 112 presentsdata and control signals from the local (or internal) network to thenon-local or foreign devices (e.g., IoT devices 102) according to aformat recognized by the non-local or foreign devices (e.g., IoT devices102). Accordingly, in various embodiments, the universal gateway 112provides seamless integration among foreign networks utilizing disparateprotocols to communicate among each other without requiring,modifications, additional programming, or configurations of the foreigndevices on the foreign networks.

Configuration of Exemplary Embodiments

The construction and arrangement of the systems and methods as shown inthe various exemplary embodiments are illustrative only. Although only afew embodiments have been described in detail in this disclosure, manymodifications are possible (e.g., variations in sizes, dimensions,structures, shapes and proportions of the various elements, values ofparameters, mounting arrangements, use of materials, colors,orientations, etc.). For example, the position of elements may bereversed or otherwise varied and the nature or number of discreteelements or positions may be altered or varied. Accordingly, all suchmodifications are intended to be included within the scope of thepresent disclosure. The order or sequence of any process or method stepsmay be varied or re-sequenced according to alternative embodiments.Other substitutions, modifications, changes, and omissions may be madein the design, operating conditions and arrangement of the exemplaryembodiments without departing from the scope of the present disclosure.

The present disclosure contemplates methods, systems and programproducts on any machine-readable media for accomplishing variousoperations. The embodiments of the present disclosure may be implementedusing existing computer processors, or by a special purpose computerprocessor for an appropriate system, incorporated for this or anotherpurpose, or by a hardwired system. Embodiments within the scope of thepresent disclosure include program products comprising machine-readablemedia for carrying or having machine-executable instructions or datastructures stored thereon. Such machine-readable media can be anyavailable media that can be accessed by a general purpose or specialpurpose computer or other machine with a processor. By way of example,such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROMor other optical disk storage, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to carry or storedesired program code in the form of machine-executable instructions ordata structures and which can be accessed by a general purpose orspecial purpose computer or other machine with a processor. Combinationsof the above are also included within the scope of machine-readablemedia. Machine-executable instructions include, for example,instructions and data which cause a general purpose computer, specialpurpose computer, or special purpose processing machines to perform acertain function or group of functions.

Although the figures show a specific order of method steps, the order ofthe steps may differ from what is depicted. Also two or more steps maybe performed concurrently or with partial concurrence. Such variationwill depend on the software and hardware systems chosen and on designerchoice. All such variations are within the scope of the disclosure.Likewise, software implementations could be accomplished with standardprogramming techniques with rule based logic and other logic toaccomplish the various connection steps, processing steps, comparisonsteps and decision steps.

What is claimed is:
 1. A method comprising: communicating over a firstnetwork associated with an Internet of Things (IoT) management systemutilizing a first communications protocol; communicating one or morestates of the virtual device over a second network associated with anIoT device utilizing a second communications protocol that is differentfrom the first communications protocol, wherein the virtual devicestores a representation of one or more states of the IoT device; andmodifying the one or more states of a virtual device based on thecommunication over the first network via the first communicationsprotocol.
 2. The method of claim 1, wherein a first network interfacecircuit is coupled to the first network and comprises a virtual networksimulation module configured to communicate with a second networkinterface circuit coupled to the second network, wherein the methodfurther comprises: generating the representation of the one or morestates.
 3. The method of claim 1, further comprising: receiving a datapacket associated with the IoT device over the second communicationsprotocol; storing the data packet according to a data structureassociated with the second communications protocol; and transmitting thedata packet to the virtual network simulation module.
 4. The method ofclaim 2, wherein the virtual network simulation module comprises avirtual network manager, the virtual network manager configured togenerate the virtual device representation based on the data packetreceived from the second network interface circuit.
 5. The method ofclaim 3, wherein the virtual network manager is configured to: generatea virtual device corresponding to the IoT device in a virtual devicetable based on the data packet, the virtual device having data objectscorresponding to data points of the IoT device; receive a data valuechange associated with the IoT device from the second network interfacecircuit; and update one or more of the data objects based on the datavalue change.
 6. The method of claim 4, wherein the virtual networkmanager is configured to initially generate the virtual device to havean offline status, and in response to receiving the data value change,the virtual network manager is configured to update the virtual deviceto have an online status.
 7. The method of claim 5, wherein the virtualnetwork manager is configured to identify a device type or address fromthe data packet, and to generate the virtual device based on the devicetype or address.
 8. The method of claim 2, wherein the second networkinterface circuit is configured to: poll the IoT device to request datavalues for one or more of the data points of the IoT device; parse thedata values to identify the data value change; and transmit the datavalue change to the virtual network manager.
 9. The method of claim 7,wherein the first network interface circuit comprises: a gatewayexecutable module configured to detect the generation of the virtualdevice and to expose the virtual device on the first network to appearas a field device on the first network, wherein the gateway executablemodule comprises a network layer configured to read data objects of thevirtual device corresponding to data points of the IoT device to detectwhen the data objects are updated and to provide the updated dataobjects to the exposed virtual device on the first network.
 10. Themethod of claim 1, wherein the second network is associated with aplurality of IoT devices, and the first network interface circuit isconfigured to generate the virtual device representation of the IoTdevice to include at least some data points from other devices of theplurality of IoT devices.
 11. A cloud-based management systemcomprising: an management platform configured to communicate over afirst network utilizing a first communications protocol, the firstnetwork comprising one or more devices associated with the firstnetwork; a second network comprising one or more devices configured tocommunicate over the second network utilizing a second communicationsprotocol that is different from the first communications protocol; and auniversal gateway device comprising: a first network interface circuitconfigured to communicate over the first network utilizing the firstcommunications protocol; and a second network interface circuitconfigured to communicate over the second network utilizing the secondcommunications, wherein the first network interface circuit isconfigured to generate a virtual device representation of a device fromamong the one or more devices on the first network.
 12. The system ofclaim 11, wherein the first network interface circuit comprises avirtual network simulation module configured to communicate with thesecond network interface circuit to generate the virtual devicerepresentation of the device.
 13. The system of claim 12, wherein thesecond network interface circuit is configured to: receive a data packetassociated with the device over the second communications protocol;store the data packet according to a data structure associated with thesecond communications protocol; and transmit the data packet to thevirtual network simulation module.
 14. The system of claim 13, whereinthe virtual network manager is configured to: generate a virtual devicecorresponding to the device in a virtual device table based on the datapacket, the virtual device having data objects corresponding to datapoints of the device; receive a data value change associated with thedevice from the second network interface circuit; and update one or moreof the data objects based on the data value change.
 15. The system ofclaim 14, wherein the virtual network manager is configured to initiallygenerate the virtual device to have an offline status, and in responseto receiving the data value change, the virtual network manager isconfigured to update the virtual device to have an online status. 16.The system of claim 15, wherein the virtual network manager isconfigured to identify a device type or address from the data packet,and to generate the virtual device based on the device type or address.17. The system of claim 15, wherein the second network interface circuitis configured to: poll the device to request data values for one or moreof the data points of the IoT device; parse the data values to identifythe data value change; and transmit the data value change to the virtualnetwork manager.
 18. The system of claim 14, wherein the first networkinterface circuit comprises a gateway executable module configured todetect the generation of the virtual device, and to expose the virtualdevice on the first network to appear as a field device on the firstnetwork, wherein the gateway executable module comprises a network layerconfigured to read data objects of the virtual device corresponding todata points of the IoT device to detect when the data objects areupdated and to provide the updated data objects to the exposed virtualdevice on the first network.
 19. The system of claim 18, wherein thesecond network comprises a plurality of IoT devices, and the firstnetwork interface circuit is configured to generate the virtual devicerepresentation of the IoT device to include at least some data pointsfrom other devices of the plurality of IoT devices.
 20. A gateway,comprising: a first network interface circuit configured to communicateover a first network associated with a cloud based management systemutilizing a first communications protocol; a first network interfacecircuit configured to communicate one or more states associated with anIoT device utilizing a second communications protocol over a secondnetwork, the second network protocol being different from the firstcommunications protocol; and a virtual device configured to store arepresentation of the one or more states of the IoT device and modifythe one or more states of a virtual device based on the communicationover the first network via the first communications protocol.